home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1191 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.8 KB
  1. Date: Mon, 1 Aug 94 09:40 CDT
  2. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  3. To: gem-list@world.std.com
  4. Subject: Digest
  5. Precedence: bulk
  6.  
  7.  
  8. vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
  9. only with graphics cards that it is faster to avoid them. And that is a tiny
  10. minority of users.
  11. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  12.  
  13. Off-screen bit-map speed could be improved for graphics cards without slowing
  14. base machines too much by scrolling the area normally, with a screen-2-screen
  15. raster operation, then redrawing the exposed portion with the off-screen map.
  16. Normally, when you use an off-screen bitmap you just use 1 raster operation
  17. since there isn't much point in breaking things into 2 separate blits.
  18.  
  19. However, for graphics card users, and for sake of consistency with other
  20. forms of redraw and scrolling, spliting the calls seems like a good idea.
  21. If redraw is the problem, and not just scrolling, then there is little
  22. one can do to redraw bit-map graphics, other than an off-screen bitmap!
  23.  
  24. Gem, itself, uses an off-screen bit-map for the menus.
  25.  
  26. vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
  27. I knew timer events worked when the menus are dropped, I think this is how
  28. Calamus etc does it. But I don't like anything using short interval timer
  29. events.
  30. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  31.  
  32. Agreed, but short timer events aren't really the problem.  The problem is
  33. what you do with them.  Polling the mouse position is rediculous to do
  34. with timer events - that is what rectangle tracking is for.  If the short
  35. timer event actually did something useful, then it would be fine, such
  36. as many animating an icon when the mouse is over it (detect the mouse
  37. being over it with rectangle events, then use timer events to draw the
  38. frames).
  39.  
  40. You can use rectangle events when the menus are down and clipping should't
  41. matter since you only need to clip your ballon help, the menu itself is
  42. already set up so that it doesn't need clipping.   I just don't understand
  43. how you are going to do the ballon help since when the menus are down,
  44. I think wind_update() is in effect, making drawing to the screen kinda
  45. hard - unless you simply don't call wind_update and draw directly to
  46. the screen.   Plus, you'll need MultiTOS (or Geneva, Mag!C, etc) since
  47. you need to be able to inquire which app owns the menu bar so you don't
  48. put your help on someone else's bar!
  49.  
  50. vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
  51. Opening windows is fairly slow under MultiTOS but not unreasonably so. What is
  52. slow about windowed dialogues is that the other windows are redrawn when the
  53. dialogue is closed.
  54. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  55.  
  56. You are basically using a raster-copy for window redraw (like we discussed
  57. above), but you are doing it only when a dialog is up.  A better solution
  58. would be to keep the dialog in a window, but make it amodal so you use
  59. the dialog and when you click on "apply" or "set" instead of "ok", the
  60. dialog stays on screen.   You'l find that being able to use such a dialog
  61. without topping it first, especially on a large screen where the dialog
  62. and window can be side-by-side, can be a nice feature.  Since this can
  63. be confusing for overlapping windows, I suggested that a button be selected
  64. only if unobscrured.
  65.  
  66. vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
  67. I agree. Programs should not put their own specific stuff into it, or it will
  68. get like the windows win.ini file.
  69. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  70.  
  71. No, I don't think so.  A good rule of thumb is that if the information
  72. will change while you run the program, then don't store it in the file.
  73. Otherwise, app-defs is perfect, and removing app-specific info would
  74. be pretty easy.
  75.  
  76. vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
  77.  > I don't want app_defs.sys turning into another win.ini.  When you install
  78.  > a Windoze program, it adds all this CRAP to your system files like
  79.  > win.ini, etc., and then when you want to remove the app, you still have
  80.  > this crap in your win.ini file.
  81. That is why I don't want to see application specific stuff in there.
  82. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  83.  
  84. The only application specific information would be a global option that
  85. you want changed per application.  There are two meanings of application
  86. specific.  One being that the option is useful only to one application.
  87. There isn't much point in putting this in a global file.   The second
  88. meaning is the option is globally useful, but you want to set it specifically
  89. for one application to over-ride the global configuration.  The first
  90. type can easily get out of hand.  The second type should be included in
  91. the file specifiction, IMHO.
  92.  
  93.  
  94.